AI-Driven Development Lifecycle (AI-DLC) Method Definition

背景と目的

ソフトウェア開発は、低レベルな作業を抽象化して生産性を高めてきた歴史がある（機械語 → 高級言語 → API → LLM）

現在は「AI支援（AI-assisted）」段階だが、AI-DLCは次の「AI駆動（AI-driven）」時代を見据える。

既存の人間中心の手法では、AIのスピードと柔軟性を十分に活かせない。

よって、AIを共同開発者（Collaborator）として位置づけた新しいライフサイクルが必要。

AI-DLCの10の基本原則（Key Principles）

再設計（Reimagine）を選ぶ：既存のアジャイルやウォーターフォールを改造せず、AIに最適化された方法を新たに設計する。

会話の方向を逆転：AIが主導して開発を進行、人間は意思決定と検証に集中。

設計技法を統合：DDD（ドメイン駆動設計）などを方法論の中心に据える。

AIの能力に合わせる：現状のAIの限界を踏まえ、人間の監督を前提にする。

複雑なシステム開発を対象：単純なローコード開発ではなく、大規模・高信頼システムを想定。

人間との共生を維持：リスク登録簿やユーザーストーリーなど、人間の理解を支える要素は残す。

習得容易性：既存の用語関係を維持しつつ、新概念「Bolt（スプリントの高速版）」などを導入。

役割の簡素化：AIによるタスク分解で役割の壁を減らし、生産性を向上。

段階を最小化し、流れを最大化：手戻りを抑え、継続的なフィードバックサイクルを実現。

固定的なワークフローを排除：AIが各開発経路に応じて最適なプランを生成し、人間が調整する。

コア構造（Core Framework）

https://gyazo.com/45029f256a14449dcbed1a0d0ff6de25

主な成果物（Artifacts）

Intent: 達成すべき目標を要約した高レベルの目的の記述

ビジネス目標、機能、技術的な成果 (例: パフォーマンスのスケーリング) など

AI 主導の実行可能なタスクへの分解の出発点となる

Unit: インテントから派生した、まとまりのある自己完結型の作業要素

測定可能な価値を提供するために設計される

例: ビジネスアイデアを実現するインテントは、独立した機能ブロックを表すユニットに分解できる

DDD のサブドメインやスクラムのエピックに類似

各ユニットには、一連のタスク (例: 機能範囲を明確に示すユーザーストーリー) が含まれる

インテントをユニットに分解するプロセスは AI によって駆動される

Bolt: AI-DLC における最小のイテレーション

ユニットまたはユニット内の一連のタスクを迅速に実装するために設計されている

スクラムのスプリントに相当

集中的な取り組みと高速デリバリーを重視

ビルド検証サイクルは数週間ではなく数時間または数日単位で測定

Domain Design / Logical Design：AIがDDD原則を用いて作成、開発者が検証。

ドメイン設計: インフラストラクチャコンポーネントとは独立して、ユニットのコアビジネスロジックをモデル化

AI-DLC の最初のバージョンでは、AI はドメイン駆動設計原則を用いて、集約、値オブジェクト、エンティティ、ドメインイベント、リポジトリ、ファクトリなどの戦略的および戦術的なモデリング要素を作成

論理設計: 適切なアーキテクチャ設計パターン（CQRS、サーキットブレーカーなど）を選択して、ドメイン設計を拡張し、非機能要件を満たすように変換

AIは、開発者による検証のためにアーキテクチャ決定レコード（ADR）を作成

論理設計仕様に基づいて、AI はコードとユニットテストを生成し、適切な AWS サービスと構成要素を選択することで、適切に設計された原則への準拠を保証

この段階で、AIエージェントはユニットテストを実施し、結果を分析し、開発者に修正に関する推奨事項を提供

Deployment Unit：テスト・セキュリティ・NFR適合を確認した実行可能アーティファクト。

開発フェーズ（Phases）

Inception (構想): インテントを捉え、開発のためにユニットに変換することに重点が置かれる

「モブ・エラボレーション」 と呼ばれる、共同で要件の詳細化と分解を行う手法が用いられる

ファシリテーターが主導し、共有スクリーンを備えた単一の部屋で行われる

モブ・エラボレーション中、AIは、ドメイン知識と、下流での迅速な並列実行のための疎結合と高凝集の原則を活用しながら、インテントをユーザーストーリー、受け入れ基準、ユニットに分解する初期の提案において中心的な役割を果たす

プロダクトオーナー、開発者、QA、その他の関連するステークホルダー（モブ）は、AIによって生成されたこれらの成果物を共同でレビューし、設計不足または過剰に設計された部分を調整し、現実世界の制約に合わせて改良する

出力には、明確に定義されたユニットと、それぞれのコンポーネントが含まれる

a) PRFAQ、b) ユーザーストーリー、c) 非機能要件 (NFR) 定義、d) リスクの説明、e) ビジネスインテントをトレースする測定基準、f) ユニット構築に使用できる推奨ボルトが含まれます。モブ・エラボレーションは、数週間、あるいは数ヶ月に及ぶ連続作業を数時間に凝縮し、モブ内およびモブとAI間の深い整合性を実現します。

Construction (構築): タスクを反復的に実行し、Inception フェーズで定義されたユニットを、テスト済みで運用可能なデプロイメントユニットに変換

このフェーズは、ドメイン設計（AIが技術的な考慮事項とは独立してビジネスロジックをモデル化）を経て、論理設計（非機能要件と適切なクラウド設計パターンを適用）へと進む

AIは、論理設計から、Well-Architectedの原則に従いながら、コンポーネントを適切なAWSサービスにマッピングすることで詳細なコードを生成します。このフェーズは、機能、セキュリティ、運用準備状況を確認するための自動テストで終了します。開発者は、各ステップでAIが生成した出力を検証し、重要な意思決定を行うことに注力し、各反復における品質と適応性を確保します。

「Mob Construction」でチームがAIと共同作業。AIがドメイン設計・コード生成・テストを実行。

Operations（運用）：

AIがログやメトリクスを監視し、異常検出や最適化提案を自動化。人間が承認。

ワークフロー

AIがまずLevel 1プランを生成。

人間がレビューして修正 → AIが詳細タスク（Level 2）に分解。

各成果物が文脈として再利用され、反復的な改良が可能。